
Applicant has corrected the dependencies. 

5. . . .Y Examples of some unclear, inexact or verbose 
terms used in the specification are: 

a. Numerous typographical errors, such as the failure of 
the applicant to end each sentence by a period followed by 
one or more spaces on lines 19 and 26 of page 1; 



Amendments have been made. 

b. Errors of grammar, such as the usage of the plural 
form of medium where the singular would have been 
appropriate on page 19, line 33; 

An amendment has been made . 

c. The usage of periods at the beginning of sentences 
or portions thereof in place of bullets, such as on lines 
6, 7, 9, 11, 15, and 17 of page 5; 

Amendments have been made. 

d. Arbitrary changes in verb conjugation between the 
third person and the second person and back again, such as 
on page 74; 



Applicant prefers not to change the text. 

e. The failure to replace place-holding text with final 
text for submission with the completed application on page 
56, lines 32-33 ("run a stored (term for interaction) with 
users 783 . ") ; 



An amendment has been made . 

f. Inaccurate transitions, such as line 1 of page 66 
("Turning now to the drawing [sic], fig. 10 illustrates... 
"with no discussion of the drawings until page 70) ; 

An amendment has been made. 

g. The definitions on pages 32 and 33 in light of the 
preceding statement on lines 13 through 15 of page 32 that 
such definitions should not be construed as limiting; 



Applicant believes that it is permitted to include an 



explanation of the manner in which the definitions should be 
construed. 



h. The use of inaccurate terms, such as "permanent 
flag" for a flag that may be reset to a different value in 
lines 16-24 of page 71; and 
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An amendment has been made. 

i. The use of the term "etc." as a specific example, 
such as on page 134, line 30 (lines 27-28 labeled each of 
the following items as examples) . 

An amendment has been made. 

6. The disclosure is objected to because of the 
following informalities: 

a. The brief description of the drawings is inaccurate 
in many respects: 

i. Figures 1 and 13 are identified as flowcharts of 
systems. Flowcharts describe methods or functions, not 
systems. 

ii. The description of figure 9 fails to note that 
it is a continuation of figure 8. 

iii. Figure 12 is identified as a flowchart of a 
database. A flowchart of a database is logically 
impossible. The flowchart may describe the process of 
adding data to the database, however. 

iv. Figures 17, 18, and 20 are not identified with 
sufficient particularity. They are not even identified as 
relating to the subject matter of the present application. 

v. Figures 21, 24, 25, 27, 28, 29, 30, 31, and 32 
are identified as relating to "illustrations of various 
views of some uses of the invention". The applicant is 
reminded that the purpose of the brief description is to 
identify separately the particular view that each figure 
represents. 

vi. The description of figure 22 is wrong. It does 
not represent either an illustration of a trigger event or 
a flowchart. Instead it is a chart relating to the 
learning curve associated with a product. 

vii. The description of figures 34A and 34B is 
insufficiently descriptive. 

Amendments have been made. 

b. Elements of the drawings are misidentif ied 
throughout the text of the specification. 

For example, items 14, 24, 26, and 30 are said to 
represent a network on lines 28 and 29 of page 36, but 
instead constitute steps of a process that does not 
require any network. Also, item 51, identified on line 4 
of page 42 as "additional I/O communications" is not shown 
in the drawings. 

Amendments have been made. 

8. The drawings are objected to because they contain 
logical errors and inconsistencies. For example, in figure 
8, element 220 states that a choice should be confirmed; 
however, that choice is not made in the flowchart. Also, 
while the flowchart in figure 8 appears to be directed 
toward the choice of certain elements by a user, it 
appears to contain directions to the programmer of the 
system as well. For example, the statement "include 
subroutines to add and delete sets" in element 218 does 
not appear to relate to a choice available to the user. 

Applicant believes that the choice indicated in element 
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220 need not be confirmed explicitly in figure 8. Applicant does 

not understand that there is any requirement that a flow chart be 

expressed from the viewpoint of only one party. 

9. The drawings are further objected to because figure 
26 contains an unnecessary textual description of the 
drawing ("This may also work in other sequences and 
arrangements."). The text should appear in the detailed 
description only. Correction is required. 



The text has been amended. Figure 2 6 is attached with 

proposed changes red-marked. 

10. The drawings are further objected to because figure 
33 is described in the brief description and on page 146 
as illustrating reuse of components. No such reuse is 
shown or suggested by the figure. Correction is required. 



As indicated on page 146 at lines 14-17, the line marked 
114 0 in figure 33 suggests the reuse. 

11. The drawings are further objected to as failing to 
comply with 37 CFR 1.84(9) (4) because reference characters 
"70" and "182" have both been used to designate the same 
display. Correction is required. 

12. The drawings are objected to under 37 C.F.R. 1.84 (o) 
because figure 21 lacks a legend identifying the various 
elements. Correction is required. 

Applicant is unclear on which elements the examiner 
believes need legends. 

14. Claims 2-5, 7, 8, 14, 16-42, and 48-53 are rejected 
under 35 U.S.C. 112, first paragraph, 

as containing subject matter which was not described 
in the specification in such a way as to enable one 
skilled in the art to which it pertains, or with which it 
is most nearly connected, to make the invention. 

Although the specification contains abundant 
description as to how to use the claimed invention and 
sufficient detail as to how to make the hardware portions 
of the claimed invention, the specification contains 
little description of how to make the software portions of 
the claimed invention other than a brief discussion of 
certain database structures on pages 105-110. The 
specification does not describe (in the case of software 
embodiments) the platform or platforms to be used, the 
division of functionality between a customer's computer 
and a manufacturer's computers, and the major modules or 
functions of the software. One of ordinary skill in the 
user feedback and user help programming arts would 
accordingly be unable to build the claimed invention based 
on the specification. 
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The first paragraph of section 112 only requires that a 
person skilled in the art to which the invention pertains be 
enabled by the description to make and use the invention. The 
examiner .acknowledges that the specification "contains abundant 
description as to how to use the claimed invention and sufficient 
detail as to how to make the hardware portions of the claimed 
invention." But the examiner argues, that the specification does 
not contain three needed pieces of information relating to the 
"software embodiments": (1) the platform or platforms to be used; 
.(2) the division of functionality between a customer's computer and 
a manufacturer's computers; and (3) the major modules or functions 
of the software. 

Applicant respectfully disagrees. 

With respect to the first item, it would be well known to 
a person skilled in the art that a variety of software platforms 
are available. A person skilled in the art would have no 
difficulty in choosing a platform that would be suitable to achieve 
the functions described in the patent application. 

With respect to the second and third items, a very 
significant proportion of the discussion on pages 35 through 138 
and pages 157 to 162, for example, provides a rich, wide ranging, 
and detailed description of examples of the functions that software 
would perform at the customer's end and at the vendor's end and of 
the manner and content of the interaction between those two ends. 
A person skilled in the art would have no difficulty, based on what 
is said in the specification, in developing software for the 
vendor's end and for the user's end that would implement the 
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invention. Given the completeness of the disclosure, applicant has 

difficulty understanding even a theoretical basis for the 

examiner's rejection. Applicant respectfully asks the examiner to 

reconsider this rejection. 

Moreover, the description of the database structures on 
pages 105-110 is of limited use due to numerous errors and 
omissions. While the description mentions a number of 
specific "fields" to include in the database, it omits to 
mention what sort of database should be used, i.e., 
relational, object-oriented, network model, etc. The term 
"field" is usually utilized in connection with relational 
databases; however, the discussion appears to assume that 
a field can be of varying size and type (such as a field 
identifying one or more sets of interactions on page 106, 
lines 13 through 22) . Thus, without greater detail 
regarding the overall structure of the database, the 
description that is given is of limited use. Other errors 
include the reference to pointers consisting of, inter 
alia, unique algorithms on page 108, lines 24 through 27 
(a pointer is an address in memory) and the statement on 
lines 9 through 22 of page 110 that text relating to any 
number of questions and answers can be entered in six 
fields, namely "answer text 1", "answer text 2", "answer 
text n", "answer data 1", "answer data 2", and "answer 
data n". Even if one of ordinary skill in the art could 
be assumed to realize that the applicant intended to state 
that a varying number of fields could be created, 
depending on the number of answers to a particular 
question, it is doubtful that one of ordinary skill in the 
art at the time would have understood how to implement the 
database structure. While one of ordinary skill would have 
been able to construct a table in a relational database 
capable of holding varying numbers of answers, such a 
table would not have included fields for the trigger event 
and other fields identified on pages 109 and 110. In other 
words, one of ordinary skill, without any direction, would 
have split up the data identified as comprising a single 
record among many records of several types located in 
several tables. While it is may be possible to implement 
a structure similar to the described structure in an 
object-oriented database, such databases were little used 
at the time and unfamiliar to those of ordinary skill in 
the art. 

Applicant believes that the specification is more than 
adequate to enable a person skilled in the art to construct an 
appropriate database or databases. Database construction is a 
widely understood activity. Database designers are capable of 
building databases that serve a variety of functions based only on 
descriptions of the results to be achieved. The applicant has gone 
far beyond the minimal information that would suffice for a 
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database developer to create appropriate structures as needed to 
achieve the results described. 

. The text at lines 13 through 22 on page 106 does not 
state that the lengths of the fields are to be variable. In any 
case, a person skilled in the art would have been able to implement 
a scheme that would track sets of interactions in the manner 
suggested in the text. That is all that is required under section 
112 . 

The same is true of the text at page 108, lines 24 
through 27. That description is fully adequate to enable a person 
skilled in the art to generate fields that provide pointers to 
related interactions, actions, constructs and data in other 
components of the invention. The "unique algorithms" are only one 
of several examples, the others being easily implemented. In any 
case, the examiner has assumed that the "unique algorithm" would 
have to be held in a field of the database. But the text does not 
require that. For example, the algorithm could be run as a way to 
find the database field that contains the appropriate pointer 
rather than being contained in the database. 

Furthermore, the specification suggests an intention to 
embed the claimed invention in a wide variety of products, 
in some as a piece of add-on hardware and in some as 
software. Therefore, the software component of the 
invention would need to exist on a vast array of 
incompatible operating platforms. The specification does 
not explain how the invention will function on such 
platforms and how compatible data will be generated. As 
a trivial example, a software manufacturer might have 
different versions of a single application for different 
versions of Unix, Windows, DOS, and the Macintosh 
operating system. Data is stored in different formats on 
different platforms. Even the byte order in which data in 
the same format is stored can differ. Constructing a 
system to automatically record, transfer, receive, and 
store data generated on different platforms is far from a 
trivial task. Where the platforms are less well known (in 
the PDA market for example) , the task becomes even more 
difficult. In this, as in many other respects, the 
applicant's conception does not appear to be complete. 
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Section 112 does not require such a description because 
it would have been well within the ability of a person skilled in 
the art to implement the invention even on incompatible operating 
platforms. Email systems and web browsing are two widespread and 
well -understood examples of how communication and data storage of 
the kind contemplated by the invention could be achieved among 
incompatible platforms. Similarly, generation of software for use 
on incompatible platforms would have been well within the ability 
of a person skilled in the art. 

Claims 2-5, 7, 8, 14, 16-22, 48 # and 52 are also rejected 
under 35 U.S.C. 112, first paragraph because the 
specification fails to provide written description or 
enablement of the element "two-way dialog". The 
specification fails to define the term "two-way dialog", 
although it does disclose "customer probes" comprising 
sets of stored prompts and questions. It should be noted 
that the responses of users cannot constitute part of the 
"two-way dialogs" because the actions of the users are not 
structural elements of the system. Thus, it is unclear 
what structural element "two-way dialog" is intended to 
define. For the purpose of applying art in this action, 
it will be assumed that the applicant intended to refer to 
(i) a set of prescripted computer prompts and questions 
(as in a user feedback system) or (ii) a set of 
prescripted computer responses (as in a help system) . 

Claims 4 8 and 52 have been amended to refer to 

"interaction scripts'*. However, applicant disagrees that 

"interaction scripts" is limited to the two examples given by the 

examiner . 

Claims 48 and 52 are also rejected under 35 U.S.C. 112, 
first paragraph because the specification fails to support 
use of the claimed feedback system with any "computer 
product". The specification discusses use of the system 
in a software application but does not disclose how 
feedback is to be handled with respect to other computer 
products, such as keyboards, mice, speakers, memory, and 
so forth. For example, it is difficult to envision how a 
user interface enabling two-way local interaction between 
the user of a mouse and the mouse could be a part of the 
product (as recited in claim 48) . For purposes of 
applying art in this action, it will be assumed that 
"computer product" was intended to include software 
applications only. Claims 2-5, 7, 8, 14, and 16-22 are 
rejected because they depend on claim 48. Claims 50 and 51 
are similarly rejected. No art will be applied by the 
examiner in this action to claims 50 and 51 because the 
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examiner is unable to determine what the applicant 
intended to claim. 



Applicant disagrees that the claims are limited to 



software products . A person skilled in the art would have 
understood that the invention could be used in hardware -based 
feedback schemes also. 



The claims that depend on claim 48 are patentable for at 



Applicant disputes the examiner's view of claims 50 and 



51 but has cancelled those claims for the moment. 



Claim 48 is also rejected under 35 U.S.C. 112, first 
paragraph because the specification fails to support 
information and questions being caused by a portion of a 
computer product to be "conveyed" from the user to the 
computer product. The specification does provide support 
for a user causing data to be stored in a computer in 
response to prompts from a software product. For purposes 
of applying art in this action, the claim will be so 
interpreted. Claims 2-5, 7, 8, 14, and 16-22 are rejected 
because they depend on claim 48. 

Applicant does not understand the rejection because it 



Claims 2-5, 7, 8, 14, and 16-22 are patentable for at 



Claim 48 is also rejected under 35 U.S.C. 112, first 
paragraph because the specification fails to support a 
"triggering mechanism". A mechanism (other than in 
chemistry) is a physical machine, or something having 
interlocking parts in a manner similar to that of a 
machine. Even if the use of the term "mechanism" can be 
considered to be proper in connection with software, the 
specification fails to reveal or suggest any single 
structure of code that would be capable of triggering the 
appropriate "dialog". For example, the specification 
suggests that a particular "customer probe" may be 
triggered by the nth use of a function, but does not 
suggest any structure in software external to that 
function designed to trigger the "customer probe". For 
purposes of applying art in this action, the "triggering 
mechanism" element will therefore be treated as a 
limitation that the software product must be able to 
display prompts, questions, or data at predetermined times 
based on data accumulated about the use of the product by 
the user. Claims 2-5, 7, 8, 14, and 16-22 are rejected 
because they depend on claim 48. 



least the same reasons. 



does not track the words of the claims. 



least the same reasons as claim 48. 
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Claim 48 has been amended. Applicant disagrees with the 



triggering elements. Trigger elements are described, for example, 
on pages 66-74 . 



The other listed claims are patentable for at least the 



Claim 48 is also rejected under 35 U.S.C. 112, first 
paragraph because the specification fails to support an 
"electronic communication mechanism" as part of a software 
product. Two electronic communication mechanisms for use 
with a computer are well known in the art, namely modems 
(with related communications software) and network 
connections hardware (with related networking software) . 
Neither one can constitute part of a software product. For 
purposes of applying art in this action, an "electronic 
communication mechanism" will be treated as software means 
cooperating with an electronic communication mechanism 
(including related software) that is not part of the 
software product. Claims 2-5, 7, 8, 14, and 16-22 are 
rejected because they depend on claim 48. 

Claim 4 8 is directed to any computer product, not only a 



The other listed claims are patentable for at least the 



Claim 52 is also rejected under 35 U.S.C. 112, first 
paragraph because the specification fails to provide 
enablement for selectively enabling and disabling the user 
interface. The applicant should note that it is not 
possible for a user to disable and subsequently enable a 
user interface. Once the interface is disabled, the user 
can no longer interact with the product in any way. In 
other words, any mechanism for enabling an interface is 
itself part of the interface and is not enabled when the 
user interface is not enabled. For the purpose of applying 
art in this office action, it will be assumed that the 
applicant intended to refer to selectively enabling and 
disabling the user feedback system. 

Applicant disagrees. The claim recites "a user 



interface". .The phrase is not necessarily meant to include every 
aspect in which the user interacts with a product. For example, 
there may be more than one user interface to a product . 



claim scope proposed by the examiner. 



The claim covers any 



same reasons as claim 48. 



software product. Claim 48 has been amended. 



same reasons . 



Claim 23 is also rejected under 35 U.S.C. 112, first 
paragraph because the specification fails to support for 
"interactive two way communication between the user and 
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the designer" of a product. Interactive communication is 
characterized by immediate, real-time responses to 
statements. The specification discloses the preparation of 
questions by the designer at the time of designing a 
product, the preparation of answers thereto by the user 
during use of the product (which is likely to be months or 
years thereafter) , and the preparation of a second set of 
questions by the designer after analyzing responses to the 
first set of questions some time thereafter (perhaps days 
but more likely months or years later) . No support is 
provided for automatically generating subsequent sets of 
questions based on free- form natural language replies by 
users to earlier sets of questions. For purposes of 
applying art in this action, the term interactive will be 
ignored throughout claim 23. Claims 24 through 42 are also 
rejected because they depend on claim 23. 

Claim 23 has been amended. The other listed claims are 

patentable for the same reasons as claim 23. 

Claim 23 is also rejected under 35 U.S.C. 112, first 
paragraph because the specification fails to support for 
running user tests of information recovered from the user 
feedback element. The specification fails to describe 
having users test the feedback, or why anyone would want 
users to test such data, or how such data should be tested 
by users, or what standards would be used to validate or 
invalidate such data in light of such tests. 

Applicant does not understand the basis of the rejection 

because claim 23 does not recite "running user tests of information 

recovered from the user feedback element." 

Claim 38 is also rejected because it depends on claim 37. 
No art will be applied to claims 37 and 38 in this action 
because the examiner is unable to determine what the 
applicant intended to claim by the language of the claim. 

Claim 37 has been cancelled. Claim 38 has been amended. 

16. Claim 8 is rejected under 35 U.S.C. 112, 2nd 
paragraph as being vague and indefinite in that the 
specification fails to explain how a trigger may be 
executed (causing a "dialog" to execute) by something that 
is both part of the product (being used locally by the 
user) and also a "remote [party]". One of ordinary skill 
in the art would not be able to determine what subject 
matter was intended to be claimed in that remote parties 
are usually thought to be natural or legal persons and 
products are not ordinarily thought to include natural or 
legal persons . Because the examiner is unable to 
determine what was intended by this claim, no art will be 
applied thereto in this action. 

Claim 8 does not recite, as the examiner suggests, that 
the trigger is executed; it recites that the triggering element is 
initiated. Applicant therefore disagrees with the examiner's 
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comments . 



Claim 16 is also rejected under 35 U.S.C. 112, 2nd 
paragraph as being vague and indefinite in that the 
specification fails to explain how an electronic 
communication mechanism can consist of a broadcast 
transmission, a wire, or a removable memory device. A 
broadcast transmission is not a mechanism: the hardware 
and associated software necessary to send a broadcast 
transmission is the mechanism. A wire is not an electronic 
communication mechanism, although it may constitute a 
small part of such a mechanism. A removable memory device 
is not such a mechanism either. It should be noted that 
sending a removable memory device by mail or by courier to 
another location does not constitute electronic 
communication any more than a human printing a message 
with a pen on a piece of paper and sending it to another 
location via the postal service (the message being capable 
of being scanned and converted to text by an OCR program) . 
For purposes of applying art in this action, it will be 
assumed that the applicant intended to claim software 
capable of cooperating with an electronic communication 
mechanism so as to transmit the relevant data by broadcast 
transmission or over a wire communication link. 

Claim 16 has been amended. Applicant disagrees with the 



assumption stated in the final sentence of the examiner's comments. 



Claim 22 is also rejected under 35 U.S.C. 112, 2nd 
paragraph as being vague and indefinite in that the 
specification fails to explain how a user could 
selectively enable and disable a user interface by means 
of a control forming part of the interface. If the 
interface is disabled, the user cannot interact with the 
control for enabling the interface. One of ordinary skill 
in the art would therefore be unable to determine the 
meaning of this claim for this reason. Because the 
examiner is unable to determine what was intended by this 
claim, no art will be applied thereto in this action. 

Claim 22 is patentable for at least the same reasons 



17. Claim 14 is rejected under 35 U.S.C. 112, second 
paragraph, as being incomplete for omitting an essential 
element, such omission amounting to a gap between the 
elements. See MPEP ? 2172.01. The omitted elements is the 
software constituting the user interface. Screens, 
keyboards, microphones, and speakers are input and output 
devices. Without an operating system or other suitable 
software, such elements are incapable of functioning as a 
user interface. For example, without suitable software, 
typing on a keyboard will not enable the user to interact 
with a computer. For purposes of applying art in this 
action, it will be assumed that the applicant intended to 
include suitable user interface software as a required 
element of the user interface in addition to the keyboard, 
display, speaker, or microphone. 

In claim 14 the "user interface" is said to "comprise 



given for claim 52 above. 
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the other elements. Although the user interface could include 

software, that is not a requirement. 

19. Claims 2-5, 7, 8, 14, 16-42, and 48-53 are rejected 
under 35 U.S.C. 103(a) as being unpatentable over Chiang 
in view of Direct Dispatch. 

With respect to claims 48 (which is interpreted as 
discussed above in paragraph 14), 49, and 2, Chiang 

, discloses an on-line tutorial system for use with software 
products running under a multitasking operating system 
(such as OS/2 or Windows) that provides a separate 
execution space in memory for each concurrently running 
program. Column 2, line 48 through column 3, line 6. The 
system includes three sets of linked panels: lesson 
panels, step panels (which are detail panels for the 
lesson panels), and concept panels. These prescripted 
explanations of the software product are displayed in 
response to user input consisting of selecting what 
subject matter is to be taught by the system. Column 3, 
lines 30 through 56. The system also includes a monitoring 
system that allows the user to execute a procedure 
explained in a lesson panel, but that generates an error 
message when the user's input is inappropriate (based on 
prescripted "triggers"). Column 3, line 57 through column 
4, line 10. Thus, the interface of the tutorial system set 
forth in Chiang provides for communication of prompts from 
the user to the tutorial system and information concerning 
the use of the product in response thereto from the 
tutorial system to the user. Moreover, the tutorial system 
is designed to include separate sets of data or lessons 
for use by users of different levels of expertise. Column 
10, lines 31 through 46. Chiang further discloses the use 
of a tutorial authoring system to generate prompts and 

> data to be displayed in response to the prompts. Column 7, 
line 41 through column 8, line 35. 

Chiang neither discloses nor suggests that the vendor of 
the software application to which the tutorial applies is in 
communication with the units of the software application with which 
users are: interacting during the tutorial. The examiner apparently 
recognizes that Chiang does not disclose or suggest, as recited in 
claims 48 and 52: (a) a communication element that carries the 
interaction scripts and results of triggered interactions between 
the units of the products and one or more remote third parties; or 
(b) a generation element that enables generation of new interaction 
scripts based on the results of previously triggered interaction 
scripts occurring at more than one of the units of the product. 
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Claim 53 recites a similar communication element. And 
claim 23 recites "two-way communication" between the user and the 
designer. 

Direct Dispatch is an application that runs under Windows 
and allows a user to open, change, track, and close 
trouble tickets concerning network problems. In other 
words, it allows a user to enter information concerning 
the use of a product in response to preprogrammed prompts. 
New Management Tools, column 1, paragraph 2; Trouble 
Management System. The trouble tickets are sent 
electronically to MCI's system for review by MCI. See New 
Management Tools, column 1, paragraph 3. 

Like the Chiang reference, Direct Dispatch lacks any 

disclosure or suggestion of the claim 48 element: " an element that 

enables generation of new interaction scripts based on the results 

of previously triggered interaction scripts occurring at more than 

one of the units of the product." The examiner seems to recognize 

that both Chiang and Direct Dispatch lack this element for he goes 

on, below, to construct an argument why that element would have 

been obvious. Direct Dispatch also lacks the step of claim 23 in 

which two-way communication is initiated based on usage of 

information accumulated at the product about use of the product by 

the user;' and also lacks the value information server of claim 53. 

It was well known in the programming arts that software 
applications, particularly new and innovative applications 
often suffer from both a steep learning curve and from 
many actual defects in the design or implementation of the 
application. Furthermore, it is well known that a new user 
of a software application often cannot distinguish between 
his lack of knowledge about the manner of operation of the 
application and actual defects in the application. 
Therefore, it would have been obvious to one of ordinary 
skill in the user training, help, and feedback programming 
art at the time who was implementing a system in 

1 accordance with the invention of Chiang to include 
functionality similar to that of Direct Dispatch in the 
system in order to allow the user to obtain help from the 
manufacturer with respect to an actual defect in the 

■ application or any feature of the application that the 
user is unable to understand in light of the tutorial. 

Applicant does not necessarily accept the examiner's 

assertions of the state of the prior art in the absence of specific 
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references. However, even if the examiner's assertions were 
correct, the inclusion of "functionality similar to that of Direct 
Dispatch in the system in order to allow the user to obtain help 
form the manufacturer with respect to an actual defect in the 
application or any feature of the application that the user is 
unable to understand in light of the tutorial" is not significant 
because such an system would not include at least one element of 
claims 4 8 and 52 that is also missing from both Chiang and Direct 
Dispatch, namely the generation element. The same is true of the 
elements of claims 23 and 53 mentioned above. Apparently, 
understanding the shortcoming of the argument, the examiner 
proceeds, to a further creation of prior art from whole cloth as 
outlined below. 

It would further have been obvious to one of ordinary 
skill in the art at the time to revise the tutorial 
lessons for a product in light of user feedback contained 
in the trouble tickets. For example, if a large number of 
tickets indicated that users failed to understand how to 
use a particular feature of the product, the explanation 
of that product might be elaborated in the next version of 
the tutorial. 

Applicant respectively suggests that the examiner's self- 
generated prior art has ventured inappropriately far afield from 
the disclosures and suggestions of the cited references. What the 
examiner 1 has done is to (1) take two references neither of which 
contains any suggestion to combine them, (2) infer that the 
suggestion would have existed, (3) reach a combination of the two 
references that lacks at least one key element of the claim, (4) 
infer, without citation of any other reference, that a person 
skilled in the art would have understood the value of a system in 
which a user would "obtain help from the manufacturer with respect 
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to an actual defect in the application or any feature of the 

application that the user is unable to understand in light of the 

tutorial" , (5) by way of that inference, reach a system that still 

does not contain key elements of the claims, (6) extend the 

inference, without citing additional prior art references, to yet 

another level in which the "explanation of that product might be 

elaborated in the next version of the tutorial", and (7) by that 

further inference, reach a system that still does not meet the 

claim language. Applicant submits that this is not a justifiable 

basis on which to reject the claims. 

It would also have been obvious to one of ordinary skill 
in the art at the time to include in the trouble ticket 
survey questions relating to the problem that gave rise to 
the trouble ticket (e.g., relating to the clarity of the 
section of the tutorial relating to the problem) because 
doing so would provide a quick and inexpensive way to 
obtain feedback from users. 

The examiner has made another unsupported inference to 
find another element of the claim in the prior art. Applicant 
respectfully asks the examiner to reconsider his position. 

With respect to claims 3 and 17, it was well known to use 
software products to analyze user feedback in order to 
improve a product. Therefore, it would have been obvious 
to one of ordinary skill in the art at the time to feed 
the data from the trouble tickets into a third party 
analysis tool and to use the results to aid in designing 
an improved version of the product in question. 
Furthermore Chiang clearly envisages use of his tutorial 
system with multiple products. . See column 1, line 10 
through column 3, line 15. 

In connection with claim 4, Chiang discloses an authoring 
system capable of generating new prompts, questions, and 
data, and interface elements related thereto, as discussed 
above in connection with claims 48, 49, and 2. It was well 
known in the art at the time to post product updates on a 
company's bulletin board for transmission to users of the 
product by downloading. Therefore, it would have been 
obvious to one of ordinary skill in the art at the time to 
generate a tutorial revised in light of data gathered from 
the trouble tickets and to post the revised tutorial on 
the company's bulletin board for downloading. 

With regard to claim 5, Chiang discloses the selective 
enabling and disabling of messages generated in response 
to user actions in the monitoring module of his system. 
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Column 16 , lines 19 through 26. 

With respect to claim 7 , it was well known that software 
running under operating systems such as OS/2 ordinarily 
executes locally. Accordingly, one of ordinary skill in 
the art at the time would read Chiang to include local 
execution of triggers. 

In connection with claim 14, computers running operating 
systems such as OS/2 or Windows ordinarily include a 
display screen, a keyboard, and one or more speakers and 
may optionally include a microphone. 

With respect to claim 16, Direct Dispatch envisions users 
communicating with MCI's computer network. New Management 
Tools, column 1, paragraphs 2 and 3. It was well known in 
the art at the time that users customarily communicated 
with remote networks by means of a telephone link, which 
is usually a form of a wire link. 

With regard to claims 18 and 19, Chiang clearly envisages 
user interface elements such as prompts including natural 
language elements such as English words, which is common 
in programs written for modem operating systems such as 
Windows and OS/2. It was well known in the art at the time 
for an application to permit the user to select the 
language to be used in the user interface. It would have 
been obvious to one of ordinary skill in the art at the 
time to allow such a choice in the case of a system in 
accordance with Chiang's invention (as modified as 
described above with respect to claims 48, 49, and 2) 
because allowing a user to interact with the system in his 
native language would increase the likelihood that the 
user could resolve his difficulties with the aid of the 
system and without needing to call technical support, 
thereby decreasing the manufacturer's technical support 
expense. 

In connection with claims 20 and 21, it is well known in 
the art that user interface elements in programs written 
for operating systems such as Windows and OS/2 permit the 
user to retain control in the process of entering data in 
dialog boxes and other user interface elements and allow 
the user to elect not to enter such data. Therefore, it 
would have been obvious to one of ordinary skill in the 
art at the time to allow the user to retain control over 
such forms of communication and to terminate such forms of 
communication. 

Without conceding any of the examiner's arguments, 

applicant notes that claims 3-5, 7, 14, and 16-21 are patentable 

for at least the same reasons as the claims on which they depend. 

With respect to claim 23, it was well known in the art at 
the time to create a first version of a product, to obtain 
feedback from users based on questions posed by the 
designer of the product, to analyze such feedback, and to 
redesign the product in accordance with the results of the 
analysis. Chiang, in combination with Direct Dispatch, as 
discussed above in connection with claims 48, 49, and 2, 
provides a method for including a user feedback element 
allowing for communication between the designer of a 
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product and the users thereof under control of the users 
and for recovering feedback data from such feedback 
element. Moreover, it would have been obvious to one of 
ordinary skill in the art at the time to include with the 
modified Chiang system a capability for the user to 
disable feedback questions when completing trouble tickets 
because it is well known that many users are annoyed by 
having to complete questionnaires. 

The examiner has reconstructed the invention of claim 2 3 

from prior art that he has inferred from personal knowledge using 

the hindsight benefit of claim 23 itself. Applicant submits this 

is impermissible. 

With regard to claims 24 through 34, it was well known for 
survey questions and answers thereto to include 
information provided by the user with respect to (i) 
problems connected with use of the product, (ii) solutions 
thereto, (iii) usability of the product, (iv) demographic 
data about the user, (v) use panems of the product, (vi) 
business processes using the product, (vii) analysis of 
tasks performed by the user with the product, (viii) 
business transactions performed by the user, and (ix) user 
suggestions concerning such matters as expansion of 
business relationships and improvements of processes. 

In connection with claim 35, Direct Dispatch allows a user 
to set a priority for response to information entered by 
the user. New Management Tools, Column 1, paragraph 3. 

With respect to claim 36, it would have been obvious to 
one of ordinary skill in the art at the time to include in 
the system in accordance with the invention of Chiang, 
combined with Direct Dispatch, as discussed above with 
respect to claims 48, 49, and 2, provision for feedback 
with respect to the interactive learning sessions 
discussed in Chiang, as noted above. 

With regard to claims 39 and 42, it would have been 
obvious to one of ordinary skill in the art at the time to 
share feedback data with third parties or otherwise grant 
access to feedback data to third parties, such as 
designers of commercial-off-the-shelf software components, 
to enable the third parties to redesign their products in 
light of the user feedback. 

In connection with claim 40, it is well known in the art 
at the time to compensate a user for his time in providing 
feedback with cash, coupons, or free product licenses 
(especially to beta testers of products) . It would have 
been obvious to one of ordinary skill in the art at the 
time to provide discount coupons or free upgrades in order 
to encourage full and frank analyses of the product by 
users thereof. 

With respect to claim 41, it was well known in the art at 
the time to buy and sell feedback data, especially 
demographic user data. Accordingly, it would have been 
obvious to one of ordinary skill in the art at the time to 
provide such a capability in Chiang's system, as modified 
by Direct Dispatch, as discussed above in connection with 
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claims 48, 49, and 2. 

Without conceding any of the examiner's arguments, 



applicant notes that claims 24 through 36 and 39-42 are patentable 
for at least the same reasons as the claims on which they depend. 



Claims 52 and 53 are rejected for the reasons set forth 
above with respect to claims 23 and 48 and the claims 
depending therefrom. 

Claims 52 and 53 are discussed above. 
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